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REMARKS 

Applicant amends claims 16, 21, 22-24, 26, 27, 29, 32 - 34. The amendments 
are supported, e.g., by paragraph [0019] of the published U.S. Patent Publication no. 
2007/0127394. New claim 37 is added and is supported, e.g., by paragraph [0019] of the 
published U.S. Patent Publication no. 2007/0127394. No new matter is added. Claim 35 is 
canceled without prejudice or disclaimer, and Applicant reserves the right to add this claim 
again at a later date and to prosecute the claim to issuance. Claims 16-34, 36, and 37 are 
presently pending. 

35 U.S.C. §101 Rejections 

The Examiner rejected claims 32-34 under 35 U.S.C. § 101 because the claims 
allegedly are directed to "non-statutory" subject matter. 

Applicant has amended claim 32 to state *'A memor vc omput e r r e adabl e 
storage m e dium storing a computer program, the computer program configured to control a 
processor to perform the following. . .". A memory should not include a transitory signal. 

Consequently, Applicant respectfully requests this §101 rejection be 

withdrawn. 

Applicant would respectfully like to disagree with the current guidelines, as 
embodied in the Eligibility Examination Instructions (and on the "Subject Matter Eligibility 
of Computer Readable Media" memorandum signed by Mr. David Kappos on 26 January 
2010). In particular. Applicant cannot determine what qualifies as a "non-transitory" 
computer readable storage medium. For instance, the guidelines apparently require the 
computer readable medium to be "non-transitory". However, most computer memory is 
transitory. RAM for example is read/write, which means that a program would be loaded into 
a part of memory (thereby potentially overwriting that portion of memory), executed, and, 
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when the program finishes operating, removed from memory. The RAM also completely 
loses its contents when the computer is shut off. Therefore, RAM is transitory. 

Moreover, even long term storage, such as hard drives and "firmware", is 
transitory in most cases: programs on hard drives can be written over, deleted, etc.; and 
firmware can be erased (e.g., using voltage or light) or written over (e.g., using voltage), etc. 
Page 2 of the Eligibility Examination Instructions gives the example of a compact disc, but 
even these are known to lose their programming, get scratched, etc., which means that the 
programming on these might be "transitory". 

The PTO's reliance on In re Nuiiten for stating that computer readable media 
cannot encompass a "signal" is misplaced. That issue was not before the court: 

Finally, Nuij ten's allowed Claim 15 is directed to " ral storage 
medium having stored thereon a signal with embedded supplemental data," 
where the stored signal has essentially the encoding properties described 
above. Thus, Nuijten has been allowed claims to the process he invented, a 
device that performs that process, and a storage medium holding the resulting 
signals. None of these claims is before us on appeal. 

In re Nuiiten , Fed. Cir., 2006-1371 page 6. 

With regard to the Eligibility Examination Instructions, these state that "a 
claim to a computer readable medium that can be a compact disc or a carrier wave covers a 
non-statutory embodiment and therefore should be rejected under § 101 as being directed to 
non-statutory subject matter" (Eligibility Examination Instructions, page 2). However, what 
is a "carrier wave"? A hard drive has a series of locations on the drive that have some 
predetermined magnetic states. What separates these predetermined magnetic states from a 
"carrier wave"? A RAM has locations corresponding to bits, and those locations are at 
certain voltage states (for instance). What separates these bits from a "carrier wave"? A 
compact disc has a series of holes on the surface of the disc, and those holes encode digital 
information. What separates these holes from a "carrier wave"? Certainly in order to read a 
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RAM, the magnetic states of a drive, or holes in a compact disc, some type of "wave" has to 
be generated and decoded. 

Applicant respectfully submits that the current PTO guidelines, as embodied in 
the Eligibility Examination Instructions, with regard to computer readable (storage) media 
make a scope of what is a "computer readable medium" undefined. 

35 U.S.C. § 102(e) Rejections 

The Examiner rejected claims 16-18, 21-25, 28, 29, 31, 32, 34, and 35 as being 
anticipated by Rune (U.S. Patent Publication no. 2004/0167988). Applicant respectfully 
disagrees. The independent claims are claims 16, 21, 22, 29, 32, and 35. 

Claim 29 appears to be one of the broader independent claims and is 
reproduced below (this claim is shown in a form prior to the present amendment). 

An apparatus comprising: 

a processor configured to 

[check] a destination address of a received packet, 

compare the destination address of the packet with at least one 
predetermined multicast and/or broadcast address, and 

prevent transmission of the packet to a first device if the 
addresses match, 

wherein the apparatus is configured to forward multicast 
messages from the first device. 

The Examiner states that the subject matter of "compare the destination 
address of the packet with at least one predetermined multicast and/or broadcast address" and 
"prevent transmission of the packet to a first device if the addresses match" in claim 29 (prior 
to the present amendments) is disclosed by Rune. Applicant respectfully disagrees. 

What Rune states regarding broadcast types is the following (emphasis added) 
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[0123] FIGS. 10-15 illustrate the coverage areas of the different 
broadcast types. The NAPS A broadcast type, as the name implies, is used to 
broadcast packets to a single NAPSA. This is illustrated in FIG. 10 (which is 
similar to FIG. 8), where each isolated gray area 1000-1008 represents a 
different NAPSA broadcast area. A NAPSA broadcast packet is not allowed 
to leave its broadcast area. Thus, NAPSA broadcast packets are not 
forwarded to the LAN and are not allowed to cross a NAPSA border. 

[0124] The scattemet broadcast type, as the name implies, is 
used to broadcast packets within the scattemet. This arrangement is illustrated 
in FIG. 11, where each contiguous gray area 1 100-1 106 represents different 
broadcast areas for a scattemet broadcast packet. Such broadcast packets are 
not forwarded to the LAN. When more than one AD exists in a scattemet, 
the scattemet broadcast packets carrying higher layer protocol packets, i.e. 
packets from protocol layers above the NAL, e.g. IP, are not allowed to cross 
an AD border. These packets are consequently limited to a part of the 
scattemet belonging to the same AD. Scattemet broadcast packets that are not 
carrying packets from higher layer protocols, such as NAL control packets, 
however, are allowed to cross AD borders and may therefore still be broadcast 
in the whole scattemet. A NAL control packet does not encapsulate data from 
a higher protocol layer and is only used to transfer signaling and control 
information between NAL entities in different Bluetooth nodes. This 
arrangement is illustrated in FIG. 12, where each contiguous gray area 1200 
and 1202 represents the broadcast area of an NAL control packet. 

[0125] The AD broadcast type covers the LAN and any 
attached scattemets that are associated with the same AD as the LAN. These 
broadcast packets are forwarded by NAPs from/to the LAN to/from the 
scattemet, but the NAPSA borders in the scattemet are respected. This 
arrangement is illustrated in FIG. 13, where each contiguous gray area 1300- 
1304 represents the broadcast area of an AD broadcast packet. An AD 
broadcast packet is used to reach all the nodes in the AD (including the nodes 
on the LAN). All broadcast packets that are forwarded from the LAN to the 
scattemet are sent using the AD broadcast type. 

[0126] The scattemet- AD broadcast type is a special broadcast 
type used only for route requests. This broadcast type is, as the name implies, a 
combination of the scattemet broadcast type and the AD broadcast type. The 
scattemet- AD broadcast packets are distributed through the entire scattemet 
without respecting the NAPSA borders, as well as the entire AD via the NAPs. 
However, the NAPSA borders are respected after a scattemet-AD broadcast 
packet re-enters the scattemet via a NAP. 
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Thus, in Rune, the NAPSA broadcast packets are not forward to a scattemet, and the 
scattemet broadcast packets are not forwarded to the LAN. However, these packets are not 
forwarded based on their broadcast type, which is defined by an indicator in a NAL (network 
adaptive layer) header (emphasis added): 

[0122] In addition to the routing protocol discussed above, the 
NAL also has a broadcast mechanism. (Note that broadcasting on the LAN is 
inherent in the shared medium and no "broadcast" mechanism is needed.) In 
accordance with embodiments of the invention, the NAL includes four 
different types of broadcasts: NAPSA broadcast, scattemet broadcast, AD 
broadcast, and scatternet-AD broadcast. The differences between broadcast 
types lie in the scope of the distribution and how the NAPs and other nodes at 
the NAPSA borders treat the different broadcast packets. Note that the 
broadcast type is defined by an indicator in the NAL header* In that sense, 
these different broadcast types can only exist in the scattemet. On the other 
hand, an Ethemet broadcast packet (originated on the LAN) that is forwarded 
from the LAN to the scattemet becomes an AD broadcast packet when it is 
forwarded into the scattemet. The broadcast type may be indicated in the NAL 
header, for example, with a two-bit indicator, as indicated in Table 2. 

Thus, the broadcast type is defined in Rune by an indicator in the NAL header. 

It is clear that filtering of broadcast packets in Rune is performed without 
examination of destination addresses for packets (emphasis added): 

[0196] The second main component of the invention is the 
packet filtering mechanism. As already mentioned, a NAP does not 
indiscriminately forward packets. Instead, it uses the packet filtering 
mechanisms (see FIG. 9) to reduce the number of unnecessarily forwarded 
packets. For example, forwarding is unnecessary when both the source and the 
destination node are located on the same side of the NAP. Furthermore, NAL 
broadcast packets of the NAPSA broadcast type and the scattemet broadcast 
type are always blocked by die packet filtering mechanisms. Only those 
packets that pass the packet filtering mechanisms are forwarded to the 
scattemet. The generated useless traffic is a waste of resources, especially so 
in the scattemet where radio resources and processing resources are scarce. 
Furthermore, this could lead to the scattemet being flooded by traffic from the 
LAN with its shared medium and much higher capacity. Therefore, a packet 
filtering mechanism is needed in order to limit the forwarding of unnecessary 
traffic. The packet filtering is based on the destination address and the NAL 
packet type. Filtering may also be based on higher layer protocols. 
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[0197] The NAL packet type filtering in the NAP is performed 
in the packet type filtering function 912, which is present only on the 
scattemet side of the NAP. The NAL packet type filtering , in some 
embodiments of the invention, is very simple: ai! NAPSA broadcast type and 
scatternet broadcast type packets are passed by the packet type filtering 
function 912 to the NAP«IPH, while all other packet types are passed to the 
address filtering function 914, 

Thus, packets having the NAPSA broadcast and scattemet broadcast types are filtered, and all 
other packet types are passed to an address filtering function, for forwarding to the correct 
address. See also, e.g., paragraphs [0222], [0224], [0237] of Rune. 

As is noted in paragraphs [0125] and [0197] from Rune above, packets having 
the AD broadcast type are forwarded, as are packets having the scattemet-AD broadcast type 
(see paragraphs [0126] and [0197]). 

Regarding multicast addresses, these appear to be related to route entries. See, 
e.g., the following: 

[0173] When (and if) the NAP-B of a NAP receives an 
encapsulated non-ARP-route-request (via the NAP-PFL), the NAP processes 
the non-ARP-route-request just like any node would process a received non- 
ARP-route-request. Thus, the NAP forwards the non-ARP-route-request into 
the scattemet, unless it already has a route to the destination node, or unless 
the NAP itself is the destination node. In the latter case, the NAP can 
immediately return an encapsulated non-ARP-route-reply. Then the next hop 
node in the route entry for the source node is indicated as "another NAP." This 
indication may be just a general indication, or it may be a specific indication 
that includes a NAP multicast address or the specific source MAC address of 
the Ethernet packet that carried the received encapsulated ARP-route-request. 
The choice between general indication, NAP multicast address or source MAC 
address depends on whether broadcast packets, multicast packets or unicast 
packets are used to carry a corresponding encapsulated ARP-route-reply. 

See also paragraphs [0156], [0186], and [0187] of Rune. There are additional references to 
"multicast" in Rune, but none of these references relate to die subject matter of "compare die 
destination address of the packet with at least one predetermined multicast and/or broadcast 
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address" and "prevent transmission of the packet to a first device if the addresses match" as 
recited in claim 29 prior to the present amendments. 

Therefore, claim 29 prior to the present amendment was patentable over Rune. 
The present amendment did not substantively amend the subject matter of "compare the 
destination address of the packet with at least one predetermined multicast and/or broadcast 
address" and "prevent transmission of the packet to a first device if the addresses match" as 
recited in claim 29 prior to the present amendments. Therefore, amended claim 29 is also 
patentable over the cited reference. 

It is noted that each other independent claim 16, 21, 22, 32, and 35 (prior to 
the present amendments) recites similar subject matter to the subject matter discussed above 
with respect to claim 29. The present amendments to these claims did not substantively 
change the similar subject matter discussed above in relation to claim 29 prior to the present 
amendments. Therefore, these other claims are also patentable over Rune for at least the 
reasons given above. 

The dependent claims 17-20, 23-28, 33, 34, and 36 are also patentable over 
Rune for at least the reasons given above. 

35 U.S.C. §103fa) Rciections 
The Examiner stated the following: 

2. Claims 19,20,26,27,30 and 33 rejected under 35 U.S.C. 103(a) as being unpatentable over 
Rune as applied to claims 16-18, 21-25, 28,29,31, 32,34 and 35 above and further in view of 
Vasisht(US 2004/0133689). 

Outstanding Office Action, page 13. Because independent claims 16, 22, and 32 are 
patentable, dependent claims 19, 20, 26, 27, 30, and 33 are patentable for at least the reasons 
given above. 
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The Examiner stated the following: 

3. Claim 36 is rejected under 35 U.S.C. 103(a) as being unpatentable over Rune as applied 
to claims 16,18,21,22^5,28,29,31,32,34 and 35 above, and further in view of Tung (US 
2006/0136562 Al) (herein after Tung), 

Outstanding Office Action, page 16. Because independent claim 22 is patentable, its 
dependent claim 36 is patentable for at least the reasons given above. 

New Claim 37 
New claim 37 recites: 

A method comprising: 

checking a destination address of a received packet; 

determining whether the destination address of the packet is a 
predetermined multicast and/or broadcast address; 

in response to a determination the destination address of the 
packet is a predetermined multicast and/or broadcast address, preventing the 
transmission of the packet to a first device; and 

in response to a determination the destination address of the 
packet is not a predetermined multicast and/or broadcast address, forwarding 
multicast and/or broadcast messages to at least the first device. 

Conclusion 

Based on the foregoing arguments, it should be apparent that the pending 
claims are thus allowable over the reference(s) cited by the Examiner, and the Examiner is 
respectfully requested to reconsider and remove the rejections. The Examiner is invited to 
call the undersigned attorney for any issues. 
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